Serving 其實包括了很多 Load Balance, Micro service architecture design 和 data flow design，所以衡量的標準大多也在 High Efficiency, High Reliability 和 High throughput 間去做和量，我任何這要完全交給 Data Scientist 負擔難免過於沈重，但知道 Serving 可能會遇到的難點是在設計機器學習方案中很重的一環，所以接下來會花五天的時間介紹一下 Serving 會遇到的幾個挑戰，首先我們先介紹一些常用的名詞，

• Load balance: 將來自用戶的請求均勻分配到多個模型實例上
• Model Sharding: 對於超大型模型，將其分成多個小塊並分散在不同的服務器上, 這技巧在 超大型 Transformer 或 CNN 架構中很常見
• Micro Service: 將每個模型或模型組件包裝為獨立的微服務，可以實現更高的模塊化和靈活性。這種方法允許團隊獨立地更新和擴展模型，而無需影響整個系統
• Data Flow and Message Queue: 如 Kafka 或 RabbitMQ 來處理非同步操作和資料流。這種機制確保了模型能夠在高吞吐率和低延遲的條件下運行
• Fault Tolerate and High availability: 分散式系統必須能夠容忍單點故障。通過多 Replica 和 Health Check，我們可以確保即使某個模型實例失效，整個系統仍能繼續運行
• Log System: 分散式環境中常會用一些集中化的日誌系統來做分析如 ELK Stack（Elasticsearch、Logstash、Kibana），可以幫助我們更有效地管理系統

All you need (to know) is Latency

上述大概提到了幾個我認為比較重要的概念，但對於 Serving 我認為核心的問題是，你 Model 做 Inference 需要多少時間？更進一步說

• 一個 Request 需要多少時間
• 同時有一萬的 Request 需要多少時間處理
• 同時有一百萬個 Request 需要多少時間處理
• 除了計算 Inference Score 外，加上 Feature 計算，要花多少時間處理
  如果能回答上面幾個問題，並且答案是一個合理可接受的數字，那基本上就完成了 Serving 這個環節

Feature Pipeline

由於我們的例子: Account Takeover Detection 本質就是一個 XGBoost Model，在 Inference 環節的 Latency 非常的低，主要的 IO (Model Loading) 可以透過像是 Singleton 的方式來避免重複讀取，所以這裡我們會將 Serving 環節的重點放在 Feature Pipeline:

我們將整個 Feature Pipeline 分長三個主要來源

1. Async Features: 非同步特徵，這類特徵的資料來源是 OLTP 資料庫，由於 OLTP 從 OLAP 把資料同步過來通常是透過定時的排程，像是每天整點同步一次，因此這類的特徵無法拿到最新的資料，通常像是 用戶過去使用過的 IP，或是過去這個 IP 常被哪些用戶使用，這種計算量大，但對時間維度沒有那麼強的實時性需求時，可以被歸類到這個 Pipeline
2. Sync Features: 同步特徵，這類特徵通常資料源是 Message Queue，有很強的實時需求，舉例來說，用戶近一小時內的 Request 次數
3. Pull Features: 我想不到好的中文，但是這個類別就是指直接透過 API 拿取的資料，同常像是用戶註冊時間等等，就可以透過這個方式拿取，但我認為這一個更適合用非同步特徵做，或許如"美金台幣匯率"這樣的特徵更適合分在這一類，但在這裡我們不會特別介紹這類特徵

除了將上述的分類外，我們會將 Pipeline 分成 Computational Component 和 Storage Component 來設計，那就讓我們在接下來的四天來介紹 Serving Section 吧！